Various editing environments exist for designing, developing, and authoring any number of applications, documents, art, or the like. The configuration of the editing environment is generally tailored to the particular output that is being edited. Application editing environments are typically code- or text-oriented, while art editing environments are typically visual- or design-oriented. Some elements, such as Web pages or Web sites, combine both an application or logic aspect as well as an artistic or visual aspect. Thus, editing environments for such cross-discipline matters may include both code or text orientation and artistic or visual orientation.
As the importance of the presentation of the Internet has grown, hypertext markup language (HTML) editors have evolved from simple code editors to visual editors that render the HTML to the designer and that allow the designer to visually edit the design while letting the HTML editor program automatically generate the underlying HTML code. HTML is a markup language that uses tags on data to define the formatting of that data. HTML is the language of the Web that describes how to present the content of the Web page to the user. HTML editors, such as MACROMEDIA's DREAMWEAVER™, MICROSOFT FRONTPAGE™, and the like, are commonly used by Web designers to generate the HTML code for Web pages and Web sites, as well as place the visual portions of the site or page. Modern Web pages and Web sites also include considerable embedded non-HTML code or script. However, HTML still forms the basis for much of the Web. Some HTML editors, such as MACROMEDIA's DREAMWEAVER™, MICROSOFT CORPORATION's FRONTPAGE™, and the like, allow editing in both a visual and a code view either separately or concurrently.
Combined editing environments, such as MACROMEDIA's DREAMWEAVER™ include both a design/visual view and a code/text view, typically both visible to the user on the same display. In the design view, developers have the ability to view and edit a Web page in a visual mode in which the HTML code has been rendered, as if on a Web browser. While the developer works on the rendered objects, the editing environment translates and effects those changes in the underlying HTML document. In contrast, the code view provides a simple text editor in which the actual HTML code is displayed to the user. The developer would typically edit the code directly when working in the code view.
In the design view mode, the HTML is usually rendered through a document object model (DOM), which is typically a tree structure that represents all of the HTML constructs. HTML is a markup language that uses tags on data to define the formatting of that data. The design view typically acts as a Web browser by rendering the HTML tags in the design view editing window. The design view internally represents the configuration of the HTML file using its DOM. The DOM basically consists of the HTML tags formed into a logical tree structure that represents the format of the HTML page. Therefore, if a developer edits a page within the design view, such as to copy and paste a paragraph to another location, the HTML editor typically takes a snapshot of the node in the DOM tree that contains the paragraph being copied and pasted and inserts that node in the newly designated place on the logical tree structure.
Because developers/users are typically allowed to work in either the design view or the code view modes, there is typically undo and redo functionality in both views. Moreover, the undo/redo in each view are usually merged or synchronized to some extent in order to fully effect changes made in either view. As a user edits a particular document in the code view and then switches to the design view, the code view edits would usually get combined together into a single step in the design view undo stack. Therefore, regardless of the number of different edits that were made in the code view, such as copying, pasting, and deleting items, when the user switches to the design view, the individual-step history would typically be lost, converted instead into a single operation in the design view undo stack. This action creates difficulties for users/developers who may generally have to work in both the code view and the design view and who wish to retain the ability to selectively undo or redo edits made in the code view. Typically, those individual edits made in the code view would usually be lost once the user enters the design view. This problem is generally encountered because most such editing environments dispose of the undo/redo stacks in the code view once the user/developer switches to the design view for any visual editing activity.
In the basic operation of undo and redo in the design view, as edits are made, there is a facility to keep track of the changes made in order to be able to undo those changes. Each time an edit is made, an edit cycle is generally executed which notifies the program that an edit is about to be made. The next steps in the edit cycle are usually the detection of changes in the DOM tree data structure and a notification that the edits are complete. At the point that the notification is received, the portion of the tree that has changed is determined and then typically copied in memory. That copy is then placed onto the undo stack. This process takes extra memory to store the edit on the undo stack. Furthermore, as each additional edit cycle is completed, another entry is added to the undo stack. When the user executes an undo command, the first entry from the undo stack is typically “popped” off. The portion of the tree that was affected is then usually placed or pushed onto the redo stack. The portion of the tree that was affected is then generally replaced with the copy from the undo stack. Thus, an undo command takes or pops one item off of the undo stack and places or pushes another item onto the redo stack.
The data structure for the undo/redo stacks are generally different for the design view and code view. In the code data structures, there is essentially a big array of characters, much like a buffer of characters. An edit may insert, delete, or replace characters. When an edit is performed, such as inserting a character, the state of the document is saved before the edit occurs. Along with the state of the document, the characters being inserted, deleted, or replaced are typically copied in memory and pushed onto the code view undo stack followed, in general, by the changes being made in the actual code data structure. The state is generally indicative of the location and range in which the edit will occur, such as the point where the character will be inserted. Along with the state, the actual inserted and/or deleted characters will then also be saved onto the undo stack. Therefore, the system keeps the information it needs in order to undo, which generally involves the edited data as well as the location where the edited data was edited. If an undo is performed, the information is generally taken off of the undo stack and placed onto the redo stack.
Because the design view is usually represented in the tree structure of a DOM, the design view data structure is also typically more like a tree data structure, instead of the character buffer of the code view. As edits are made in the design view, a snap shot of the portion of the DOM tree structure that was changed is placed onto the design view undo stack unlike the code view undo stack which just places a copy of the characters. The undo/redo operations operate similarly from that basic difference.
When the developer switches focus from the design view to the code view, or vice versa, the two views are typically synchronized to reflect the edits made in one or the other views. For example, when the developer makes edits in the design view, but then switches focus to the code view, the system basically takes the entire DOM tree and writes the entire page out again as source code in the code view screen. Therefore, each time an edit is made in the design view, the entire code view is replaced with the new, corresponding code. This synchronization is generally faster than when synchronizing a move from the code view to the design view. This is so because there are generally pre-determined code blocks associated with visual edits made in the design view. Therefore, when the system detects the change in a node of the DOM tree, a pre-determined chunk of code is available to be generated directly into the code view.
This pre-determined information is typically not available when moving from the code view to the design view because the code, which is entered in an ad hoc fashion by the developer, is parsed and processed before the resulting visual elements can be known or viewed. Therefore, the synchronization after going from the code view to the design view is relatively slower. When changes are made in the code view the entire code view buffer is typically passed to the design view to be parsed, after which the DOM tree structure is generated. The new DOM tree data structure will then usually be compared by the design view to the existing DOM to determine exactly which portions of the file have changed. Once the change has been detected, that portion of the DOM tree structure is replaced by its change in the new DOM tree structure. Thus, the changes made in the code view are reflected in the design view.
FIG. 1 is a block diagram illustrating typical editing environment 10 having design view 100 and code view 101. Because the content of design view 100 is typically rendered from HTML or some such other markup language, its format can generally be broken into a representative DOM tree structure with the content of the HTML file represented by the nodes of the tree. As the user performs edits in design view 100, editing environment 10 takes snap shots or copies of the changed nodes and saves them into undo stack 102 (or redo stack 103) along with some additional information on the location of the edited node. Conversely, in code view 101, undo stack 104 and redo stack 105 are usually simple arrays that hold a certain number of characters entered into code view 101 along with some additional information of where the code edit occurred.
Because existing editing environments tend to include both a design view and a code view, methods for synchronizing and combining the two views and their respective undo/redo stacks have been implemented. Undo stack 102 and redo stack 103 of design view 100 include code view edits in code undo entry 106 and code redo entry 107. The operation of both views, design view 100 and code view 101, is very different. The mechanism for processing instructions design view 100 and code view 101 instructions is also very different.
In practice, when a user switches from editing in code view 101 to editing in design view 100, editing environment 10 assembles undo stack 104, which comprises each step entered in the code view, into a single design view 100 action such as code undo entry 106. Editing environment 10 usually purges or deletes undo stack 104 or redo stack 105 of code view 101 once the user switches to design view 100 and transfers undo stack 104 into a design view undo entry, such as code undo entry 106. Therefore, several different edits made during an edit session in code view 101, would be represented by a single design view 100 undo action, such as code undo entry 106. While this solution brings both design view 100 and code view 101 edits into the same design view 100 undo 102 and redo 103 stacks, it generally does not allow for a singular code view 101 edit to be singly undone or redone once the user switches to design view 100. Furthermore, because editing environment 10 usually erases undo/redo stacks 104 and 105 upon transferring the contents of undo stack 104 to design view 100, the ability to access the individual edits from code view 101 may be lost forever.